home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000117_connolly@pixel.convex.com _Mon Jun 8 05:39:39 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA10313; Mon, 8 Jun 92 05:39:39 MET DST
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA00160; Mon, 8 Jun 92 05:37:46 +0200
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA12756; Sun, 7 Jun 92 22:37:31 -0500
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA28980; Sun, 7 Jun 92 22:37:29 -0500
  10. Message-Id: <9206080337.AA28980@pixel.convex.com>
  11. To: jfg@dxcern.cern.ch (Jean Francois Groff)
  12. Cc: www-talk@nxoc01.cern.ch
  13. Subject: Re: revised MIME architecture 
  14. In-Reply-To: Your message of "Mon, 08 Jun 92 00:41:18 +0200."
  15.              <9206072241.AA24685@dxcern.cern.ch> 
  16. Mime-Version: 1.0
  17. Content-Type: multipart/mixed; boundary=cut-here
  18. Date: Sun, 07 Jun 92 22:37:29 CDT
  19. From: Dan Connolly <connolly@pixel.convex.com>
  20.  
  21.  
  22. --cut-here
  23.  
  24. >    Dan,
  25. >
  26. >  OOPS... You sent this one to www-interest instead of www-talk...
  27. >I'm getting ready for some flamage from clueless list members :-)
  28. >
  29. Did I? I sent several messages, and I though I was careful to
  30. send them all to www-talk. Oh well... Sorry!
  31.  
  32. >  Regarding your proposal, the idea is exciting, although I find it
  33. >annoying that small documents, like most HTML pages are, will suddenly
  34. >take 4 times as much storage and bandwidth due to verbosity.
  35. >
  36. They won't necessarily take 4 times as much storage: the verbose part
  37. _could_ be generated on the fly. by the server.
  38.  
  39. On the other hand, it _is_ simpler to store things in the format that
  40. they'll be used. This brings up the issue of authoring documents in
  41. this format. I'm developing some ideas on interactive composition
  42. of MIME messages (using EMACS, FrameMaker, or perhaps a Tk application)
  43. but for now, it's somewhat tedious.
  44.  
  45. >  I'd like to develop on this, but I lack MIME background and, believe
  46. >it or not, I couldn't find the MIME RFC in the archive indexes ; could
  47. >you tell me (and the list) its number? Also, pointers to existing MIME
  48. >readers would be welcome.
  49. >
  50. I've gotten several "nifty... so what is MIME?" responses. So I'll
  51. tell you what I told them...
  52.  
  53. --cut-here
  54.  
  55. >Where can I get more information about MIME?
  56. >
  57. >            Thanks.
  58.  
  59. The author of the rfc is Nathaniel Borenstein <nsb@thumper.bellcore.com>.
  60. Most of the publicly available material is on thumper.bellcore.com in
  61. pub/nsb.
  62.  
  63. --cut-here
  64. Content-Description: RFC-XXXX (MIME)
  65. Content-Type: multipart/alternative; boundary=alt
  66.  
  67. --alt
  68. Content-Type: message/external-body;
  69.     access-type=ANON-FTP;
  70.     site=thumper.bellcore.com;
  71.     dir=pub/nsb;
  72.     name="BodyFormats.txt"
  73.  
  74. Content-Type: text/plain
  75.  
  76. --alt
  77. Content-Type: message/external-body;
  78.     access-type=ANON-FTP;
  79.     site=thumper.bellcore.com;
  80.     dir=pub/nsb;
  81.     name="BodyFormats.ps"
  82.  
  83. Content-Type: application/postscript
  84.  
  85. --alt--
  86.  
  87. --cut-here--
  88.